Organized software development generally follows well-defined styles that provide recognizable and repeatable structures, much like other disciplines (e.g., civil engineering, culinary arts, graphic design, etc.). Structure enables the consistent implementation of constraints to achieve specific desired properties. Three leading software architectural styles are Object Oriented Development, Service Oriented Architecture, and Representational State Transfer.
In the Object Oriented Development (OOD) style, an object is a set of dependent data and functions. Each encapsulated object is an artifact that has a custom interface providing for its manipulation. Objects can be loosely-coupled, but are not individually addressable by a remote system without extension (e.g., common object request broker architecture, CORBA). In the context of an application, object bindings are often prescribed as fixed components of the system. The use of any interaction context to customize system responses is left to the software developer in defining an object. Overall, the OOD style supports rich software applications, but the tight-coupling within, and often between objects, limits the practical range of result customization.
In the Service Oriented Architecture (SOA) style, a service is a set of dependent data and functions. Each encapsulated service is a black-box artifact that has a custom interface defining the fixed range of its manipulation. Services are loosely-coupled and can be individually addressable components in a distributed system. In the context of an application, the SOA style requires a meta application layer for messaging, translation, and binding. This layer is typically supported by discrete middleware components (e.g. enterprise service bus (ESB), business process execution language (BPEL), business process management (BPM), etc.). The use of any interaction context to customize system responses is left to the software developer in defining a service interface. Overall, the SOA style supports rich software applications, but the tight-coupling within services and the black-box nature of services intrinsically limits the practical range of result customization.
In the Representational State Transfer (REST) style, a resource is any discrete element of information (e.g. document, database record, temporal service, etc.), independent of any pre-determined function, that can be referenced with a unique address (e.g., Uniform Resource Indicator, URI). Each resource is a standalone artifact that has a standard interface (e.g., the Uniform Interface) providing for its manipulation, however manipulation is done through representations, which isolate a resource from direct interaction. Resources are loosely-coupled and addressable components in a distributed system. In the context of an application, every resource is a potential state addressable by a client, therefore each client request results in a representation and a new application state. The use of any interaction context to customize system responses is constrained to in-band context provided with the client request, the software developer is prohibited from using any out-of-band context that may reside on the server. Overall, the REST style supports rich software applications, but the absence of pre-determined functions, and the inability to use server-side context, results in a client driven application that intrinsically limits the practical range of result customization.